node:net: do not push native reads into a socket whose readable side has ended - #42262

… socket (#42265)

Fixes #32239.

### Problem
- Regression from #42213. `tls.connect({ socket })` over a `net.Socket`
built with `readable: false` reports `ERR_STREAM_PUSH_AFTER_EOF` on the
wrapped socket during the handshake. That destroys the connection before
any data arrives.
- Cause: after TLS adopts the fd, the raw half still hands the
ciphertext to the wrapped socket. `pushDataToSocket`
(`src/js/node/net.ts:443`) pushes it into the ended Readable. The same
leak calls a wrapped `onread`, re-enters `'data'` listeners left from
STARTTLS (`Invalid socket`, #32239), and fills a buffer that nothing
reads.
- `net.connect({ readable: false, onread })` never calls `onread`. The
`readableEnded` checks from #42213 keep the handle stopped. Node starts
it whenever an `onread` buffer is set
([net.js#L830-L845](https://github.com/nodejs/node/blob/v26.3.0/lib/net.js#L830-L845)).

### Fix
- Data on the adopted raw half (`kAdoptedTLSRaw`) is dropped before the
push and before the `onread` callback. Node's `TLSWrap` takes over the
handle's reads
([wrap.js#L723-L727](https://github.com/nodejs/node/blob/v26.3.0/lib/internal/tls/wrap.js#L723-L727)),
so the wrapped socket never sees the TLS stream. Its idle timer is still
refreshed.
- The `readableEnded` checks in `resume()`, `read()` and
`afterConnect()` exempt a socket with an `onread` buffer.
- Verified: `node-tls-upgrade.test.ts` (`readable: false`, `onread`, no
reader, STARTTLS on both peers) and `node-net.test.ts` (`onread` +
`readable: false`). A build of main's `src/` fails all five.

### Background
- `tls.connect({ socket })` and `new tls.TLSSocket(socket, { isServer:
true })` adopt the connected fd. The native call returns a TLS handle
and a raw handle. The raw handle stays on the original `net.Socket`
(`kAdoptedTLSRaw`) and receives each ciphertext chunk.
- A Duplex built with `readable: false` starts with `endEmitted` set, so
`push()` reports `ERR_STREAM_PUSH_AFTER_EOF`.
- `onread` makes a `net.Socket` read into the caller's buffer and skip
the Readable.

<details><summary>Notes</summary>

**Repro 1, TLS over a `readable: false` socket**

```js
const raw = net.connect({ port, host: "127.0.0.1", readable: false });
raw.on("connect", () => {
  const s = tls.connect({ socket: raw, ca, servername: "localhost" });
  s.on("secureConnect", () => s.write("hi"));
  s.on("data", d => console.log("data", String(d)));
});
```

- node v26.3.0: `secureConnect | data "banner" | data "echo:hi"`
- bun 1.4.2: `secureConnect | data "bannerecho:hi"`
- main: `raw error ERR_STREAM_PUSH_AFTER_EOF | secureConnect | tls end |
raw close | tls close`

**Repro 2, `onread` + `readable: false`.** Node's `read()` / `resume()`
start the handle whenever an `onread` buffer is set, whatever the
Readable state, and `afterConnect` calls `read(0)`. Main reads nothing.

**Results against node v26.3.0**

| | node v26.3.0 | main | this branch |
|---|---|---|---|
| TLS over `readable: false` | `banner`, `echo:hi` |
`ERR_STREAM_PUSH_AFTER_EOF`, no data | `bannerecho:hi` |
| `onread` + `readable: false` | `"banner"` | `""` | `"banner"` |
| wrapped `onread` socket, TLS bytes seen | 0 | 2790 | 0 |
| STARTTLS, `'data'` calls on the wrapped sockets after the wrap | 0 | 4
(client and server) | 0 |
| wrapped socket `readableLength` after a 16 MiB TLS transfer | 0 |
16,802,694 | 0 |
| repro script of #32239 | upgrade succeeds | `Invalid socket` on the
third `'data'` call | upgrade succeeds |

The last three rows also fail on the released 1.4.3. They come from the
same leak and are older than #42213.

**More checks on this branch**

- `bytesRead` of the wrapped socket still counts the TLS bytes on the
push path, like node (the TCP handle counts every byte it reads).
- A 300 ms `setTimeout()` on the wrapped socket does not fire while TLS
traffic arrives every 100 ms, like node (`_unrefTimer()` still runs
before the drop).
- The event order on the wrapped socket and on the TLS socket is the
same as on 1.4.3 in these cases: the peer ends first, the client calls
`end()` first, each with a plain, a `readable: false` and an
`allowHalfOpen` wrapped socket.

**Suites**

- `test/js/node/tls/node-tls-upgrade.test.ts` (5),
`node-tls-connect.test.ts` (55), `node-tls-server.test.ts`,
`test/js/node/net/node-net.test.ts`,
`test/js/node/http2/node-http2-upgrade.test.mts` (15),
`test/js/bun/net/socket-retention.test.ts` (5),
`test/regression/issue/{12117,40401}.test.ts`.
- The 30 vendored `test-tls-*` / `test-https-*` files that wrap a socket
in TLS.
- The author ran `node-http2.test.js` (380 pass) on the first commit.
The second commit changes only tests.

**Related PRs**

- #42262, opened in parallel, returns early in `pushDataToSocket` when
`readableEnded`. That fixes the `ERR_STREAM_PUSH_AFTER_EOF` case. It
does not fix `onread` + `readable: false`, which comes from the
`readableEnded` checks in `resume()` / `read()` / `afterConnect()`. It
also still hands the TLS stream to a wrapped socket whose readable side
is open or that has an `onread` buffer. Both PRs touch the top of
`pushDataToSocket`, so the one that lands second needs a one-line
rebase.
- #36534 reworks the upgrade in native code so that the ciphertext is
never dispatched to JS. This PR drops it in the JS handler, which is
enough for the wrapped socket to see nothing.

**Not addressed here**

- `bytesRead` stays 0 on every socket built with `onread`, wrapped or
not. The `onread` data handler never counted. This is also the case on
1.4.3. It has its own report.
- A wrapped socket that goes through the stream-level TLS engine (a
named pipe on Windows, or a socket with pending writes) feeds that
engine from its `'data'` events. With `readable: false` it emits none.

</details>

<!-- robobun:evidence:begin -->

---

**no test proof** · iteration 1 · platform-specific test(s) that do not
run on this machine, deferring to CI, which covers all platforms:
test/js/node/net/node-net.test.ts

<!-- robobun:evidence:end -->

---------

Co-authored-by: robobun <117481402+robobun@users.noreply.github.com>